Released Request Impact Analysis

This workflow runs the Smart Impact Analysis workflow to perform an impact analysis for any newly-released requests on the Analysis system, identified by the Find Released Requests workflow. These requests provide the changing objects that are used in the analysis.

The Excel report returned by the Smart Impact Analysis workflow is emailed to the specified recipients.

The depth used by the workflow to search for referenced objects may be set by an Administrator in the Configuration - Impact Analysis screen’s ImpactAnalysisDepth field. If you don't set this field, the workflow uses 10 as the default value.

The workflow should be scheduled to run periodically. During each run, an Impact Analysis is performed for the transportable tasks from the analysis system that have not yet been processed.

The workflow populates charts in the Dashboard screen.

Parallel impact analysis

You can run the Released Request Impact Analysis workflow in parallel with other impact analysis apps and workflows.

Prerequisites

We recommend that you configure the Daily FOL workflow to run each night. This workflow maintains a database of SAP object dependencies for your Analysis system.

The Released Request Impact Analysis workflow uses a Pipeline to identify:

The Analysis, Comparison, Usage and SAP Solution Manager systems to be used in the analysis.
One or more Most-at-risk Search Test Repositories that will be searched to find test assets that match the most-at-risk executables.
A Most-at-Risk Gaps Test Repository, in which test requirements are to be created for most-at-risk objects that don't have matching test assets in the specified search Test Repositories.
One or more Most-at-risk Hits Execution Test Repositories, in which tests that match most-at-risk objects are to be created and executed.

Before the Released Request Impact Analysis workflow is run, you must create a Pipeline that includes the appropriate systems. In the Pipeline:

The Analysis System field stores the RFC Destination for your Analysis system.
The Comparison System field stores the RFC Destination for the system on which to compare the most-at-risk executables.
The Usage System field stores the RFC Destination for the system from which performance history data has been obtained.
If required. the SAP Solution Manager System field stores the RFC Destination to the RFC Destination from which to retrieve the ChaRM IDs associated with each transportable task.
The Most-at-risk Search Test Repositories fields store the Test Repositories in which the most-at-risk objects are searched to find hits and gaps. Each Most-at-risk Search Test Repository may have one or more search paths to limit the folders that are searched. Each path should begin with the Subject folder, and a backslash (\) should be used to separate path components, for example Subject\Release1.
The Most-at-risk Gaps Test Repository field stores the Test Repository in which to create requirements for most-at for most-at-risk objects that don't already have requirements in the Tosca, qTest or ALM Most-at-risk Search Test Repositories. Requirement names have the format LiveCompare_Most-at-risk_Gaps <YYYY-MM-DD HH:MM:SS> <Object Name - Object Description>.
The Requirements Path field the name of the root requirements folder to be used in the specified Tosca Most-at-risk Gaps Test Repository. If you don't set this field, the workflow uses Requirements as the default value.
The Most-at-risk Hits Execution Test Repositories fields store the Test Repositories in which execution lists are to be created. For each most-at-risk hits execution Test Repository:
- Set the Execution Name field to the name of the test execution folder in which execution lists are to be created.
- Set the Execution Path field to the to the path of an existing Test Repository folder in which to store the test executions, for example Execution/TestExecutions. If you don't set this field, LiveCompare creates the test execution in the default Executions folder.
- Set the Execution List Path field to the path of an execution list to reuse when creating Tosca test executions, for example, Execution/MyTests/LiveCompare_2023-01-31 09:47:17/MyExecutionList.
- Set the Options field as appropriate to either create test runs, or to create and run test runs. Executing tests requires Tosca to be configured using DEX.

Disable Table Content Analysis

If the Pipeline’s Disable Table Content Analysis checkbox is checked, table content changes will be excluded from the changing objects used in this app. If it is unchecked, table content changes will be included.

The Create Object Links Cache workflow from the Prerequisites templates folder should be run to create an object links cache database for the Analysis system.

You should make sure that performance history data is available on the RFC Destination selected for the Performance History System. Select the RFC Destination in the LiveCompare hierarchy and click the PHD tab. Select the source for performance history data, set a collection schedule, click Save, and then click Update Cache. See the Retrieve performance history data help topic for details.

The ChangingObjectsToIgnore External Data Source removes tables whose names begin with ENH or AGR from the set of changing objects.
The TransportsToIgnore External Data Source contains regular expressions which are used to filter out transports containing custom objects.
The UsedObjectsToIgnore External Data Source contains used objects that are to be ignored during the analysis.

If required, these External Data Sources may be edited in the LiveCompare studio using the ‘Replace Data File’ option.

The Initialize Request Store workflow should be run in your Configurator Impact Analysis workspace, as described here.

LiveCompare should be configured to send emails. see the Guided Configuration- Email help topic for details.

Prepare the workflow

The Released Requests Impact Analysis workflow should be run in a separate workspace for each system to be analyzed. To prepare the Released Requests Impact Analysis workflow, follow these steps.

Create a new workspace whose name reflects the system to be analyzed, for example RRIA - <Analysis System>.
Copy the Templates > Impact Analysis > Initialize Request Store workflow to the RRIA - <Analysis System> workspace.
Select the Templates > Impact Analysis > Released Request Impact Analysis template in the LiveCompare hierarchy and choose Copy to Workspace from the context menu.
Select RRIA - <Analysis System> as the target workspace, and click Copy. Several dependent templates will also be copied.
If required, configure the Initialize Request Store workflow to set the date from which to retrieve released requests. See the template’s help file for details.
Run the Initialize Request Store workflow in the RRIA - <Analysis System> workspace.

Select the Released Requests Impact Analysis workflow in the RRIA - <Analysis System> workspace, and configure the workflow as follows.

Set the Pipeline parameter to the Pipeline that includes your RFC Destinations and Test Repositories.
Set the Compare ABAP? Boolean parameter to specify whether the most-at-risk objects will be compared on the Analysis and Comparison systems.
Set the Compare Data? Boolean parameter to specify whether the table keys for changing tables will be compared on the Analysis and Comparison systems. If this parameter is set to true, up to 20 table keys will be compared for each changing table.
Set the Email To String List parameter to a list of email recipients for the Developer Impact Analysis report. Each email address should be stored a separate string entry.
Set the From String parameter to the EmailFromAddress value stored in the Configuration - Email screen. You may need to check this setting with a LiveCompare Administrator.
Customize the Subject String parameter and Message String Multiline parameter as appropriate.

Express and Standard modes

The Released Request Impact Analysis workflow runs in either Express or Standard mode, depending on whether its changing objects all exist in the database of SAP object dependencies you created here.

If the Released Request Impact Analysis workflow’s changing objects are all in the dependencies database, it runs in Express mode. The workflow’s Find Object Links (Read Only) action reads the dependencies database directly and doesn’t need to connect to SAP to find any object dependencies.
If the Released Request Impact Analysis workflow’s changing objects aren’t all in the dependencies database, it runs in Standard mode. The workflow’s Find Object Links (Read Only) action connects to SAP to find the missing dependencies.

The Released Request Impact Analysis workflow typically runs much faster in Express mode.

Schedule the workflows

The Released Request Impact Analysis workflows should be run using a schedule. The following workflows will need to be scheduled. To schedule a workflow, select it in the LiveCompare hierarchy and choose Schedule Run from the context menu.

Create Object Links Cache

This workflow should be copied from the Prerequisites templates folder to each of your DIA - <Analysis System> workspaces. It should be configured to create an object links cache database for the analysis system and then scheduled to run once each week. If possible, the workflow should be scheduled to run when no developer tasks are being performed on the analysis system (for example, outside office hours).

Released Request Impact Analysis

This workflow runs the Smart Impact Analysis workflow to perform an impact analysis for any newly-released requests on the Analysis system, and sends report links to the specified email recipients. It should be scheduled to run as required on a daily basis, for example several times each day, depending on how frequently you wish to review the impact analysis reports.

Workflow results

The Released Request Impact Analysis workflow generates the following reports:

Smart Impact Analysis Dashboard

The Released Request Impact Analysis workflow generates a Dashboard which includes the following charts:

The Used, Impacted & Most-at-risk column chart provides a summary of the number of custom and standard used, impacted and most-at-risk objects.
The Most-at-risk & Test Coverage doughnut chart provides a summary of the number of hits and gaps found for the most-at-risk objects in the specified Test Repository.
The Changing Object Summary doughnut chart summarizes the changing objects by their change type.
The Most-at-risk & Test Coverage by Type column chart summarizes by type the most-at-risk objects, and the objects with hits in the specified Test Repository.
Dashboard tiles display the date of the analysis, the name of the Analysis system, the name of the Performance History system including the date range for which performance history data was obtained, and the name of the Test Repository that was searched to obtain matching test assets.

The Dashboard’s Additional Resources section includes links to the following Excel reports:

Function Details Report

The Function Details Excel report includes the following spreadsheets:

Dashboard

This spreadsheet includes the following charts:

The Used, Impacted & Most-at-risk column chart provides a summary of the number of custom and standard used, impacted and most-at-risk objects.
The Most-at-risk & Test Coverage doughnut chart provides a summary of the number of hits and gaps found for the most-at-risk objects in the specified Test Repository.
The Changed Object Summary doughnut chart summarizes the changed objects by their change type.
The Most-at-risk & Test Coverage by Type column chart summarizes by type the most-at-risk objects, and the objects with hits in the specified Test Repository.
The Top 5 Application Areas bar chart lists the top 5 Application Areas, in terms of the number of most-at-risk objects in each Application Area.
The All, Covering and Optimal Tests column chart lists the number of found tests in each Application Area, the number of tests that cover at least one most-at-risk object, and the optimal number of tests that cover each of the most-at-risk objects.
Dashboard tiles display the date of the analysis, the name of the Analysis system, the name of the Performance History system including the date range for which performance history data was obtained, and the name of the Test Repository that was searched to obtain matching test assets. The number of change IDs and transport objects are also shown.

Home

The Home spreadsheet provides a summary view of all the Application Areas found during the analysis. It has the following columns:

APP_AREA

The name of the Application Area in which the objects were found. (None) is used for objects that don't have an Application Area.

NOT_IMPACTED

The number of used objects in the Application Area that are not impacted by a changing object.

IMPACTED

The number of used objects in the Application Area that are impacted by a changing object, but not most-at-risk.

MOST_AT_RISK

The number of used objects in the Application Area that are impacted and most-at-risk; these are recommended for testing.

TEST_HITS

The number of most-at-risk objects in the Application Area that are covered by at least one test in the Pipeline’s Most-at-risk Test Repository.

TEST_GAPS

The number of most-at-risk objects in the Application Area that are not covered by any tests in the Pipeline’s Most-at-risk Test Repository.

IMPACTFUL_CHANGES

A count of the distinct impacting objects for each Application Area’s most-at-risk objects.

App Area Details

This spreadsheet lists the most-at-risk, impacted and not impacted objects, and their associated Application Areas and descriptions. It includes:

Impacted objects with one or more impactful changes (these objects are marked as most-at-risk).
Impacted objects with no impactful changes.
Used objects with no impactful changes.

The APP_AREA column displays the name of the Application Area in which the objects were found. (None) is used for objects that don't have an Application Area.

The STATUS column displays the status of each object, either Most-at-risk, Impacted or Not Impacted.

The usage count and number of users for each object is listed, obtained from the available performance history data. Click a hyperlink in the USERS column to display the users in the Impacted Users spreadsheet. Note that the USERS column is blank for objects whose status is ‘Used’.

The RISK column displays H, M, or L for most-at-risk objects. These values are a ranking of risk due to the depth of the impact and frequency of use of the object. H is for high risk, M is for medium risk, and L is for low risk.

The IMPACTFUL_OBJECTS column displays the number of changing objects that impact each object. Click a hyperlink in this column to display the impacting objects in the Impactful Objects spreadsheet. New most-at-risk objects (that have no impactful objects and a usage count of 0) are set to have themselves as a single impactful object.

The TESTS column lists the number of optimal tests chosen for the object in the TYPE and NAME column in the specified Test Repository. Click a hyperlink in this column to display the matching tests in the Test Hit Details spreadsheet.

The CUSTOM column is set to Y for custom used, impacted and most-at-risk objects.

The BUSINESS_CRITICAL column is set to Y for objects included in the Business Critical Objects External Data Source.

Impactful Objects

This spreadsheet lists the changing objects introduced by the transports, ChaRM change requests or objects analyzed by the Released Request Impact Analysis workflow. The spreadsheet lists used impacted objects in the NAME and TYPE columns, and the changing objects that impact them in the CHILD_NAME and CHILD_TYPE columns. The DEPTH column indicates the search depth at which the impacted object was found.

The CHANGE_ID column identifies the transport or ChaRM request that includes the impacting object. This column is set to Objects if the changing object was specified in a list of objects.

For each used impacted object, the DYNP column lists the number of impacted screens for the object in the most-at-risk results. Click a hyperlink to display the object’s impacted screens in the Impacted DYNPs spreadsheet.

If a Comparison system has been specified and the Compare ABAP? parameter has been set, the CHILD_STATUS column lists the comparison status for the object on the Analysis and Comparison systems specified in the Released Request Impact Analysis workflow’s Pipeline. Click a hyperlink in the CHILD_NAME column to display comparison details for the selected object.

Impacted DYNPs

This spreadsheet lists changing objects in the CHILD_NAME and CHILD_TYPE columns, their used impacted objects in the NAME column, and their associated screens, screen numbers and descriptive text in the DYNP_PROG, DYNP_NUM and DTXT columns.

Click a hyperlink in the NAME column to display tests that include the object in the Test Hit Details spreadsheet. If a hyperlink is selected in the Impactful Objects spreadsheet’s DYNP column, the Impacted DYNPs spreadsheet lists the impacted object’s associated screens.

Impacted Users

This spreadsheet lists the type and name of each impacted object, and its usage count for each user according to the available performance history data. Each user’s type is also shown. Click a hyperlink in the NAME column to display the associated test in the Test Hit Details spreadsheet. If a hyperlink is selected in the Impactful Objects spreadsheet’s USERS column, the Impacted Users spreadsheet lists the users of the impacted object.

Test Hits & Gaps

This spreadsheet indicates whether each most-at-risk object is a hit, a gap or a known gap in the specified Test Repository.

Hits are most-at-risk object names for which test assets have been found.
Gaps are most-at-risk object names for which there are no available test assets.
Known gaps are most-at-risk objects that are not expected to have tests in the specified Test Repository. These are set in the Pipeline’s Known Test Gaps External Data Source.

Test Hit Details

This spreadsheet includes the details for each test asset in a specified Most-at-risk Search Test Repository that matched a most-at-risk object, including the test name, test path, and tested object. If the spreadsheet is accessed via a hyperlink, it displays the details for the linked test asset.

For ALM Test Repositories, the TEST_LIST_ID, TEST_LIST_NAME and TEST_LIST_PATH columns store the ID, name, and path of the execution list or test set for each test hit.

Each test is given a rank, either H (High), M (Medium) or L (Low), based on how recently it was last run, its passes and fails, the number of runs per day, and the number of test steps. More highly ranked tests should be prioritized over tests with a lower rank.

Test Data

If a Comparison system has been specified, and the Compare Data? parameter has been set, this spreadsheet lists the SAP tables referenced in tests that match the most-at-risk objects recommended for testing. The type and name of each Most-at-risk Search Test Repository is listed, along with the matching test’s name and ID.

The name of the referenced table is displayed in the TABLE_NAME column. Click a hyperlink in this column to display an Object Differences report showing data differences for the table on the Analysis and Comparison systems specified in the Released Request Impact Analysis workflow’s Pipeline.

Help

This spreadsheet provides help for each of the spreadsheet reports.

Testing Details Report

The Testing Details Excel report includes the following spreadsheets:

Dashboard

This spreadsheet includes the following charts:

The Used, Impacted & Most-at-risk column chart provides a summary of the number of custom and standard used, impacted and most-at-risk objects.
The Most-at-risk & Test Coverage doughnut chart provides a summary of the number of hits, gaps and known gaps found for the most-at-risk objects in the specified Test Repository.
The Changed Object Summary doughnut chart summarizes the changed objects by their change type.
The Most-at-risk & Test Coverage by Type column chart summarizes by type the most-at-risk objects, and the objects with hits in the specified Test Repository.
The Top 5 Application Areas bar chart lists the top 5 Application Areas, in terms of the number of most-at-risk objects in each Application Area.
The All, Covering and Optimal Tests column chart lists the number of found tests in each Application Area, the number of tests that cover at least one most-at-risk object, and the optimal number of tests that cover each of the most-at-risk objects.
Dashboard tiles display the date of the analysis, the name of the Analysis system, the name of the Performance History system including the date range for which performance history data was obtained, and the name of the Test Repository that was searched to obtain matching test assets. The number of change IDs and transport objects are also shown.

Home

The Home spreadsheet summarizes the tests found in the Pipeline’s Most-at-risk Search Test Repository by Application Area. It has the following columns:

APP_AREA

The Application Area associated with the tests. Click a hyperlink in the APP_AREA column to display the App Area Details spreadsheet filtered to display the optimal tests in the selected Application Area.

ALL

The number of distinct test IDs associated with any tested object belonging to the Application Area. Test IDs are found in the Test Repository cache generated for the Released Request Impact Analysis workflow’s Pipeline.

COVERING

The number of distinct test IDs in the set of test hits that are associated with any tested object belonging to the Application Area. A test hit is a test asset in the Pipeline’s Most-at-risk Search Test Repository that matches a most-at-risk object.

OPTIMAL

The number of distinct test IDs in the set of optimal test hits that are associated with any tested object belonging to the Application Area.

TEST_GAPS

The number of objects in the test gaps set that are associated with the Application Area. A test gap is a most-at-risk object that doesn't have a matching test in the Pipeline’s Most-at-risk Search Test Repository.

App Area Details

This spreadsheet lists tests that match objects that have been identified as most-at-risk. It includes the Application Area in which the object was found, the type and name of each Most-at-risk Search Test Repository where a matching test was found, including the path, name and ID of each matching test.

The STATUS column is set to Optimal if the test is in the set of optimal tests to run, or to Covering if the test covers at least one most-at-risk object.

The TEST_DATA column lists the number of SAP tables referenced in tests that match the most-at-risk object recommended for testing. Click a hyperlink in this column in this column to display the table names in the Test Data spreadsheet.

The TESTED_OBJECTS column lists the number of objects that are covered by the test. Click a hyperlink in this column to display the tested objects in the Test Hit Details spreadsheet.

Test Data

If a Comparison system has been specified in the Released Request Impact Analysis workflow’s Pipeline, and the Compare Data? parameter has been set in the app, this spreadsheet lists the SAP tables referenced in tests that match the most-at-risk objects recommended for testing. The type and name of each Most-at-risk Search Test Repository is listed, along with the matching test’s name and ID.

The name of the referenced table is displayed in the TABLE_NAME column. Click a hyperlink in this column to display an Object Differences Reports showing data differences for the table on the Analysis and Comparison systems specified in the Released Request Impact Analysis workflow’s Pipeline.

Test Hit Details

This spreadsheet includes the details for each test asset in a specified Most-at-risk Search Test Repository that matched a most-at-risk object, including the Application Area associated with each test, the test name, test path and tested object. If the spreadsheet is accessed via a hyperlink, it displays the details for the linked test asset.

For ALM Test Repositories, the TEST_LIST_ID, TEST_LIST_NAME and TEST_LIST_PATH columns store the ID, name, and path of the execution list or test set for each test hit.

Each test is given a rank, either H (High), M (Medium) or L (Low), based on how recently it was last run, its passes and fails, the number of runs per day and the number of test steps. More highly ranked tests should be prioritized over tests with a lower rank.

Test Hits & Gaps

This spreadsheet indicates whether each most-at-risk object is a hit, a gap or a known gap in the specified Test Repository.

Hits are most-at-risk object names for which test assets have been found.
Gaps are most-at-risk object names for which there are no available test assets.
Known gaps are most-at-risk objects that are not expected to have tests in the specified Test Repository. These are set in the Pipeline’s Known Test Gaps External Data Source.

Changes

This spreadsheet lists the changing objects introduced by the transports, ChaRM change requests or objects analyzed by the Released Request Impact Analysis workflow. The spreadsheet lists used impacted objects in the NAME and TYPE columns, and the changing objects that impact them in the CHANGE_NAME and CHANGE_TYPE columns. The DEPTH column indicates the search depth at which the impacted object was found.

Click an object link in the CHANGE_NAME column to display a comparison report for the object on the Pipeline’s Analysis and Comparison systems.

The CHANGE_ID column identifies the transport or ChaRM request that includes the impacting object. This column is set to Objects if the changing object was specified in a list of objects.

If a Comparison system has been specified and the Compare ABAP? parameter has been set, the CHANGE_STATE column lists the comparison status for the object on the Analysis and Comparison systems specified in the Released Request Impact Analysis workflow’s Pipeline. Click a hyperlink in the CHANGE_NAME column to display comparison details for the selected object.

Help

This spreadsheet provides help for each of the spreadsheet reports.

Analysis Input Data

This Excel report contains a copy of the input parameters used to produce the workflow’s Dashboard report. The value of each input parameter is stored in a separate worksheet, which is named after the parameter whose value it contains.

Released Request Impact Analysis

Parallel impact analysis

Prerequisites

Disable Table Content Analysis

Prepare the workflow

Express and Standard modes

Schedule the workflows

Create Object Links Cache

Released Request Impact Analysis

Workflow results

Smart Impact Analysis Dashboard

Function Details Report

Dashboard

Home

App Area Details

Impactful Objects

Impacted DYNPs

Impacted Users

Test Hits & Gaps

Test Hit Details

Test Data

Help

Testing Details Report

Dashboard

Home

App Area Details

Test Data

Test Hit Details

Test Hits & Gaps

Changes

Help

Analysis Input Data

Related topics